The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In computer networks such as the Internet, packets of data are sent from a source to a destination via a network of links (communication paths such as telephone or optical lines) and nodes (usually routers directing the packet along one or more of a plurality of links connected to it according to one of various routing protocols).
Referring to FIG. 1 which shows a block diagram illustrating an overview of a data communication network, the network is designated generally 10 and includes a network of nodes and links shown by “cloud” 12 with routers 14, 16, 18. The routers 14, 16, 18 are connected to routers, servers or clients (only one is shown for each router in FIG. 1 but multiple routers, servers or clients can of course be supported) providing access to the Internet. Referring to FIG. 1 a local access router 20 connected to the router 14 comprises a Home Agent (HA), a foreign access router (FA) 22 is connected to router 16 and a server 24 is connected to the router 18 and comprises a Correspondent Node (CN). Communication between the routers 20, 22 and server 24 is possible across the Internet. In this description the local access router 20 is also termed a Home Agent 20 and the server 24 is also termed a Correspondent Node 24.
One issue of increasing importance as regards data communications networks relates to processing data traffic involving a mobile node. For example referring to FIG. 1 a Mobile Node 26 (MN) comprising a laptop computer is connected to the home agent 20. When it is desired to communicate between the mobile node 26 and the correspondent node 24 this is straightforward while the mobile node is connected to its home agent. The manner in which communication is carried out is dependent upon the communication protocol adopted but prevalent protocols are Internet Protocol version 4 (IPv4) and version 6 (IPv6) which are described at the time of this writing in the files “rfc791.txt” and “rfc2460.txt” respectively in directory “rfc” of the domain “ietf.org” on the World Wide Web. In particular a mobile node has a home address (at its home agent) such that while it is connected to its home agent it uses its home address as source address and the correspondent node can reply simply by using the mobile node's home address as the destination address allowing straightforward communication according to the protocol. However if the mobile node 26 moves to a position as shown in dotted lines in FIG. 1 and connects to foreign access router 22 then evidently the mobile node's home address will not be sufficient for communication with the correspondent node 24 to be continued.
One existing solution to deal with this is to assign the mobile node 26 an attachment address or “care of address” when it attaches to a foreign access router 22. The mobile node establishes whether it is connected to the home agent 20 or to a foreign access router 22 by receiving and processing a “Router Advertisement” from the entity to which it is connected which will include information about the subnet that it is connected to, in order for the MN to build a care of address. If the MN is at home then the agent address is also included within this information. When the mobile node 26 detects that it is at a foreign access router 22 then to find its Home Agent it sends a Dynamic Home Agent Address Discovery (DHAAD) request packet and awaits a DHAAD reply. It then sends a “binding update” (BU) message to the home agent 20 via the foreign access router 22 using its new care of address as the source address, and including a home address option as discussed in more detail below. The home agent 20 uses the binding update message to update its “binding cache” of addresses with the care of address. The binding cache is a table maintained by the home agent 20 of all mobile nodes 26 which are away from home at a foreign access router. The table maps the mobile node's home address to the care of address that it is currently using. If there is not an entry in the table for the given home address, then it is assumed that the mobile node is on the home network. In practice additional authentication steps may take place which are facilitated because the mobile node 26 and its home agent 20 are in a common security regime.
The procedure when a correspondent node 24 corresponds with a mobile node 26 which is not connected to the home agent 20 is shown in FIG. 2 which depicts a network diagram illustrating one known solution to communication between a mobile node and a correspondent node. Because the correspondent node and mobile node are not in the same security domain they cannot simply authenticate each other. Accordingly the correspondent node 24 sends a packet to the mobile node's home address, i.e. the home agent 20 along a link 25 joining the two. The home agent 20 establishes from its binding cache the current care of address of the mobile node 26 and forwards the packet along a link 27 to the mobile node 26 via the foreign access router 22 to which the mobile node 26 is currently attached. If the mobile node 26 replies then the message is once again channeled via the home agent 20. For the purposes of security or transparency the home agent 20 tunnels the packets between the correspondent node 24 and mobile node 26, i.e. encapsulates data packets received from one party in a larger packet destined for the other party, with or without encrypting the original data packets. There is no direct communication, therefore, between the mobile node 26 and the correspondent node 24 which can introduce delays in communication. This approach, known as “dogleg routing” provides a level of transparency for the correspondent node upper layer protocols (i.e. at the level of determining source and destination values for packets).
Improved solutions are disclosed in internet protocol versions 4 and 6 in relation to mobility support (mobile IPv4/IPv6) as set out at the time of this writing in the file “rfc3220.txt” in directory “rfc” and in the file “draft-ietf-mobileip-ipv6-19.txt” in directory “internet drafts” respectively of the domain “ietf.org” on the World Wide Web. In particular “Mobility Support in IPv6” uses the technique of “return routability”. Referring to FIG. 3, which shows a network diagram illustrating a further known solution to communication between a mobile node and a correspondent node, as with the previous solution, the mobile node 26 sends a binding update to the home agent 20 along the link 27 such that the home agent 20 maintains an updated binding cache. On initiation or maintenance of a communication path or link between a mobile node 26 and a correspondent node 24, the mobile node 26 simultaneously sends two different authentication packets to the correspondent node 24.
The first packet is sent using its home address as source, such that the packet must travel via the home agent 20. Therefore the mobile node encrypts and reverse tunnels the packet to the home agent 20 along link 27. The home agent decrypts and decapsulates the packet, and forwards it along link 25 to the correspondent node 24. The encrypted tunnel ensures that the packet can only be seen along link 25.
The second packet is sent using its-care-of-address as the source, thus the packet can be sent directly to the correspondent node 24 via link 28.
On receiving each packet the correspondent node 24 sends a response back to the mobile node 26, using the source address of the first packet as the destination address. Thus the first packet is destined for the home address, and travels along link 25 until the home agent 20 intercepts, encrypts and tunnels it via link 27 to the mobile node 26.
The correspondent node also sends a response packet destined for the care of address, which travels direct via link 28.
Using these two packets, the mobile node 26 can build a common secret which only it and the correspondent node 24 shares, providing return routability. As a result route optimisation can be performed. Thus the mobile node can now send an authenticated BU to the CN, and the mobile node 26 and correspondent node 24 can communicate directly along the link 28. Each time the mobile node 26 moves, once the link 28 has been set up direct communication can continue.
However a disadvantage of this approach is that the correspondent node, as it now deals directly with the mobile node's care of address, has to maintain a binding cache and also carry out route optimisation including return routability authentication steps. This is a significant burden both on the correspondent node memory and processing capabilities which can divert resources from its core server functionality. This can render a server particularly vulnerable to a denial of service attack wherein the multiple route optimisation operations are instigated by a malicious third party.